Description of the FRS domain

An FRS helps in the reservation of facilities (such as tutorial rooms, hotel rooms, lecture theaters) and specific equipment. Different organizations such as academic institutions, hotels, hospitals and companies, have different physical facilities and arrangements for their reservation. Most often, users (individuals or organizations) manage their own reservations with an FRS (e.g., add, delete and modify their own reservations). In some companies, however, users send reservation requests to a middleman who makes reservations for them. An FRS may allow certain users to manage facilities (e.g., add new facilities). In general, users may only perform certain functions according to the permissions assigned to them. An FRS will typically allow users to print out a variety of reports. The calculation of reservation charges, if any, may be performed according to discounts associated with each user and the payment classification of each facility. Below we list some of the FRS variants: 1. Different institutions have different physical facilities and different rules for making reservations. 2. FRS may need support multiple methods for viewing reservations. In addition to viewing by facility ID (mandatory), FRS may need support viewing reservations by reservation ID and/or by the date. 3. There is a high level of variability in user permissions. In some FRSes, permissions are given across the board to a whole group of users; at other times, there may be a need to individually specify the permissions that each user has. 4. Some FRSes may need manage a database of all the users and/or facilities in a company. One should be able to add new user/facility, enter the proper description and delete an existing user/facility. 5. Some FRSes should also allow the user to search for available facility (e.g., a meeting room) with the necessary piece of equipment. 6. Sometimes a payment must accompany the reservation. The calculation of reservation charges, if any, may be performed according to discounts associated with each user and the payment classification of each facility. The FRS domain can be considered a sub-domain (i.e., specialization) of the general object allocation domain [28] In case of the FRS, an “object” is a facility, whether it is a room, equipment or even a person. The object allocation domain supports the allocation of an object to another object, which is usually an agent. The allocated objects are typically returned after a period of time for subsequent reallocation. Sub-domains of the FRS domain include offices, academic institutions, hotels, recreational and medical facilities and transportation (e.g., airlines, trains). These sub-domains are not mutually exclusive and the intersection of sub-domains forms a generic core of the FRS domain. In practice, scoping a product line is done before detailed domain analysis and design of a product line architecture [29] During scoping, we identify areas of concern that are worth the domain engineering effort. These areas of concern may cover different dimensions of a product line such as functional requirements, platform dependencies, runtime concerns (such as component structure, component communication, synchronization and performance), system-wide qualities (such as security, reliability and availability) and many others. Having explicitly engineered a given area of concern within a product line architecture, we expect to efficiently manage variants within that area during system engineering and architecture evolution. Scoping a product line is driven by business factors we should address a given area of concern only if expected benefits outweigh the domain engineering effort. In this paper, we do not precisely define or further justify the scope of an FRS product line from business perspective.